It is common practice for computer-based servers to digitally stream media content (e.g., video, music, text, graphics, and the like), live or on-demand, to electronic devices, such as mobile smartphones, tablets and the like, for viewing by a user. Such media content is often provided to the user devices (or clients) via the internet using a distributed network of computer-based data file servers deployed in one or more data centers, also referred to as a content delivery network or content distribution network (collectively, CDN). A typical CDN structure may be a hierarchical tree format, where if a client requests digital media content or asset from a nearby edge node and that node does not have the asset, it goes to its parent node and the like, until it finds the desired asset. Once a client has requested an asset from a node, the asset remains available for some period of time at that node for future clients, thereby providing an efficient file delivery web architecture.
HTTP-based streaming methods, such as HLS (HTTP-based Live Media Streaming communication protocol), supported or implemented by products made by companies such as Apple, Inc., HDS (HTTP Dynamic Streaming), supported or implemented by products made by companies such as Adobe, Inc., and DASH (Dynamic Adaptive bit-rate Streaming over HTTP) or MPEG-DASH, are commonly used for streaming media content and operate using “HTTP-based streaming,” where media content is stored in segments or “chunks” of a predetermined length (e.g., 1 to 10 seconds) and a playlist (or manifest or index) file is provided that lists, or points to, each of the segments or chunks of the media stream for display or playback purposes by the user devices. Such HTTP-based streaming methods are highly scalable to permit high traffic (i.e., many clients requesting video), which helps bring content out to the edge of the network and makes efficient use of the CDNs, and CDN service providers, such as Akamai, Level3, and the like. More detailed information regarding HTTP-based streaming can be found at: Pantos, HLS Draft Specification: tools.ietf.org; DASH Industry Forum: dashif.org; and Binary data over websocket: binaryjs.com, the contents of which are incorporated by reference to the extent needed to understand the present disclosure to the extent permitted by applicable law.
However, such HTTP-based streaming methods suffer from significant network overhead as well as high latency for a given client/user and variable latency from encode to display among different clients/users. In particular, in an HTTP-based streaming environment, clients (e.g., smartphones, tablets, and the like) must repeatedly poll, or sample the status of, the server for new available media content and reload the playlist/manifest file that lists the segments of the media stream that are available for viewing by the user. Each time a client requests a new manifest file from the server, it opens a “socket” connection, negotiates a handshake, exchanges header information, and receives the manifest file, which requires significant network overhead.
In addition to network overhead associated with the repeated polling, such HTTP-based method also introduces more latency for a given client and a wide variation of latencies between different clients. More specifically, if a client requests and loads the manifest immediately after the manifest is updated with a new segment file, the client will experience minimum latency. If a client requests and loads the manifest just prior to it being updated with a new segment file, the client will experience maximum latency. Thus, on average, the additional latency for a given client is about one-half of the segment file duration, thereby causing the client's viewing experience to be delayed. In addition, because different clients request and load updated manifests at different times, the latency is not consistent from one client to the next, thereby creating a different viewing experience for different clients.
For example, if two users (or clients) are sitting next to each other viewing the same sporting event (from the same video stream) on their respective smartphones, one user may see that a team has scored before another user. This can create a less than optimal viewing experience for the users.
Another streaming approach is “push-based” streaming, such as RTSP (Real Time Streaming Protocol) or RTMP (Real Time Messaging Protocol, by Adobe). With “push-based” streaming methods, a persistent (or continuous) connection between a server and a client is created (or opened) and the video data is “pushed” from the server to the client on a continuous basis. In that case, streaming video is typically accomplished by opening a “socket” connection and pushing video data down the connection where the client would receive it, decode it, and display it. Such an approach can reduce latency that would be inherent in an HTTP-based polling approach discussed above; however, it requires a significant dedicated infrastructure in a content delivery network (CDN) because a given server can only handle a certain number of client connections at one time, and thus does not scale well to permit high traffic.
Accordingly, it would be desirable to have a system or method that improves the short-comings of existing video streaming techniques and that enables improved performance of digital streaming to provide a better viewing experience for the user.